google-site-verification: google8bce9cd167a02a39.html

Cumulative content of Working Group Meetings in 2025

Date: 20/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica. Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • ESPD

  • eRequest

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

The ESPD #413 ticket was discussed again:

  • It was mentioned that information such as the one mentioned in the ticket should be Additional Information.

  • It was decided this should not be of class cccev:Evidence, as it is currently modeled and it should be modeled differently.

  • There is a need for a superclass other than Evidence.

Information on the eRequest concept was given:

  • It is a request for an offer in a Framework agreement, and its response. It is also related with mini-competition.

#691 was discussed:

Concerning the review diagram:

  • Class epo:ReviewObject was removed.

  • Attribute epo:hasNumberOfReviewRequests of class epo:ReviewRequest was removed.

  • Attribute epo:hasRequestDate of class epo:ReviewRequest was removed.

  • Attribute epo:hasDecisionDate of class epo:ReviewDecision was removed.

XVxSWHlipzP508HXYb+TrZhqLSQMxb0WIeqsoYFEvNoNW9KGNzSvO1ku+w4BQgg0zmcHm7f9MnJafINAADwOf4Pfiay9DofS+YAAAAASUVORK5CYII=

  • Class epo:ReviewRequest became a specialization of epo:Document.

  • Class epo:ReviewDecision became a specialization of epo:Document.

  • Predicate epo:specifiesReviewRequester [0..1] with domain epo:ReviewRequest and range epo:ReviewRequester was added.

  • Predicate epo:specifiesReviewer [0..1] with domain epo:ReviewDecision and range epo:Reviewer was added.

  • Attribute epo:hasElementReference xsd:anyURI [0..*] was added to class epo:Document.

  • Attribute epo:hasNumberOfReviewRequests xsd:integer [1] was added to class epo:ReviewRequestSummary.

x+37mPe5mgmFQAAAABJRU5ErkJggg==

Concerning the completion notice relations diagram:

  • Predicate epo:announcesReviewObject [0..*] with domain epo-not:CompletionNotice and range epo:ReviewObject was removed.

BxVaz2ggl6AeAAAAAElFTkSuQmCC

  • Predicate epo:refersToReviewRequest [0..*] with domain epo-not:CompletionNotice and range epo:ReviewRequest was added.

3PY8YFIfEgAAAAAASUVORK5CYII=

Concerning the result notice relations diagram:

  • Predicate epo:announcesReviewObject [0..*] with domain epo-not:ResultNotice and range epo:ReviewObject was removed.

G4HdyAAAAABJRU5ErkJggg==

  • Predicate epo:announcesReviewRequest [0..*] with domain epo-not:ResultNotice and range epo:ReviewRequest was added.

V3Q9F4LDgAAAABJRU5ErkJggg==

Action Points

  • Create github issue for TED mappings repository informing for the changes done in this WGM regarding the review concepts.

WG meeting

Date: 18/02/2025
Participants: Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding discussions

Discussions

The eAwarding Ontology Requirements Specification Document (ORSD) was further developed. Specifically:

The following Roles are involved in eAwarding:

  • Unique Responsible of the Procurement – played by a Person; it is part of the Buyer’s Organization (the head of the Organisation; the person that has the final decision)

  • Buyer

  • Tenderer

  • Winner

  • Candidate

The Award Decision is based on the Evaluation report. The Unique Responsible for the Procurement either accepts the findings of the Evaluation Report, or takes another decision (in case the winner does not fulfill all the criteria for the award of the contract).

The Activity description section was written as follows:

  1. The Award Decision is written by the Unique Responsible of the Procurement.

  2. The Unique Responsible of the Procurement *ensures *the evidences for the Participation Conditions and the Qualification Criteria are fulfilled by Tenderers proposed for an Award.

    1. If the evidences are good, the Award Decision is signed by the Unique Responsible of the Procurement.

    2. If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer:

      1. If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.

      2. If the clarification confirms that the evidence is not good, the evidences of another Tenderer(s) are checked until we reach the required number of Winners

  3. The Tenderers are notified about the result through one of the following:

    1. Award Decision is* published* on the Buyer’s website

    2. Award Notification is *sent *to the Tenderers

  4. A standstill period (while the contract cannot be signed) of one month starts from the notification to allow other Tenderers to request Review.

  5. At the end of the standstill period the Contract can be signed.

  6. No later than 30 days after the conclusion of a Contract, a Result Notice must be published.

The following Use cases were added:

Use case Description Actors Flow

The Award Decision is written

The Award Decision is* written *by the Unique Responsible of the Procurement.

Unique Responsible of the Procurement

The Unique Responsible of the Procurement writes the Award Decision based on the Evaluation Report.

Participation Conditions and the Qualification Criteria are checked

The Participation Conditions and the Qualification Criteria are assessed.

Unique Responsible of the Procurement

The Unique Responsible of the Procurement ensures the Participation Conditions and the Qualification Criteria are fulfilled by checking the evidences referenced/written in the ESPD.

Clarifications from the non-compliant Tenderer are required

If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer.

Unique Responsible of the Procurement,

If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.

The Award Decision is signed

The Award Decision is* signed* by the Unique Responsible of the Procurement.

The Unique Responsible of the Procurement signs the Award Decision.

The Tenderers are notified about the result of the procurement.

The Award Decision is published on the Buyer’s website OR an Award Notification is sent to the Tenderers.

Buyer, Tenderer

The Tenderers are notified about the result through one of the following:

It was noted that the Qualification Response should be in another module.

WG meeting

Date: 13/02/2025
Participants: Peter Borresen, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eFulfilment Receipt advice data model.

Discussions

ResponseStatus codelist was put at the level of AbstractContainer as seen on the diagram below:

H5Xn0ZjodhkAAAAASUVORK5CYII=

  • Further Questions regarding the fields of the Receipt advice data model were answered.

There was a further discussion with the ESPD team regarding ticket https://github.com/OP-TED/ESPD-EDM/issues/413:

ifgrKMX2H2zvDuRfsHvL8X1IeYSPsXONd414Af9bHOLW53p7aRQSBAAAZQsCAAAAHsRs1En5PC6dyqVR97c2CGurADxS+9tbTAYNAgCAsgUBAAAAH43LYbOYdAAeNS0EAADl6i9mow4AAMBHkcsk0hMRAI+aQacufW8DAMoBBAAAAAAAAABlBAIAAAAAAACAMgIBAAAAAAAAQBmBAAAAAAAAAKCMQAAAAAAAAABQRiAAAAAAAAAAKCMQAAAAAAAAAJQRCAAAAAAAAADKCAQAAAAAAAAAZQQCAAAAAAAAgDICAQAAAAAAAEAZ+YvZoAUAAAAAAACUif8PzaVVo+oY6acAAAAASUVORK5CYII=

  • Add a Github Issue about renaming that highlighted property seen in the diagram above in order to cover for the parts mentionerd in the https://github.com/OP-TED/ESPD-EDM/issues/413 depicted in the figures below. A possible name could be epo:canProvideEvidence Also the attribute coversAllSelectionCriteria should be at the level of the evidence.

wVeP3KRaHQkZgAAAABJRU5ErkJggg==
NEoAnahOUDlAJ0r066cE0InqBCWATlSJlAA6UZ2gBNCJKpESQCeqE5QAOlElUgLoRHWCEkAnqkRKAJ2oTlAC6ESVSAmgE9UJSgCdqBIpAXSiOkEJoBNVIt0NoP8vVgGQgLO74ooAAAAASUVORK5CYII=
YAAOCH4IflPIFWBgAAAAAAgBi0MgAAAAAAAMQubNBXAQAAAAAAAHjQygAAAAAAABCDVgYAAAAAAIAYtDIAAAAAAADEoJUBAAAAAAAgBq0MAAAAAAAAMWhlAAAAAAAAiEErAwAAAAAAQAxaGQAAAAAAAGLQygAAAAAAABCDVgYAAAAAAIAYtDIAAAAAAADEoJUBAAAAAAAgBq0MAAAAAAAAMWhlAAAAAAAAiEErAwAAAAAAQAxaGQAAAAAAAGIXGOsrAAAAAAAAADxoZQAAAAAAAIhBKwMAAAAAAEAMWhkAAAAAAABi0MoAAAAAAAAQg1YGAAAAAACA2P8DpCv8rdb3tWQAAAAASUVORK5CYII=
TNKnbu3LlixYrFixdv2bLlf0tyk6VLl3bdaR4MeAbxCNnW1tZwSuUbNmw48HitCLNu3bpkG4mjEUk4EolE09EJ4UgkEt0ESTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJRBKORCLRdCThSCQSSTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJRBKORCLRdCThSCQSSTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJxL+CcIwbN2716tWNJxKJRLfB3LlzZ86cGSnmE4lE98TKlSsnTpzYRMLxzjvv9OvXb9CgQZr570Qi0f0wadKkvn373nXXXdYejecSiUT3AA4wYMAAZAAraCQKB8EhE462trYFCxbMnj27tbX174lEovvB3G9paZk5c+acOXMazyUSiW4DTGDJkiVYQSNROAgOmXAkEolEIpFIHCqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOv4PU9iXAmDDf2wAAAAASUVORK5CYII=

Action Points

  • Create a Github Issue to implement Object Line Identifier with the predicate SalesOrderLineID.

  • Add a Github Issue about renaming that highlighted property mentioned above.

WG meeting

Date: 11/02/2025
Participants: Natalie Muric, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding ORSD

Discussions

A new definition for the epo-sub:ESPD was given according to the diagram below:

YhHDjQwf8HyKKBj3YrX28AAAAASUVORK5CYII=
iYEVMACWswAAAABJRU5ErkJggg==
8feK1wv8CGG+r2ojXfSqQZ20QwFEwxBxz7fuK3+P10AOg8b1wyWAAAAAElFTkSuQmCC

Issue #734 was updated accordingly, and epo-sub:ESPD and ePO-acc:ESPDRequest: were updated accordingly.

The WG started discussing about the ORSD for the eAwarding module.

ESPD-EDM https://github.com/OP-TED/ESPD-EDM/issues/423 and https://github.com/OP-TED/ESPD-EDM/issues/413 issues were discussed:

  • #423:

    • eForms and UBL are not aligned, ESPD is aligned with UBL.

    • A qualifying party has a codelist that describes the role. So ESPD is covered by this. 423 can thus be closed.

  • #413

    • It was discussed that although the specific field mentioned in issue #413 covers multiple lists or equivalent certificates, in the ePO there are no Lists.

    • It was mentioned that the information conveyed by that specific field is not used as an evidence for any criterion and that it should be modelled as additional information and not evidence.

Working Group Meeting

Date:30/01/2025  
Participants: Peter Borresen, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Alignment with PEPPOL for eFulfilment #569.

Discussion

  • Alignment with PEPPOL for eFulfilment #569.

    • Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.

Action Points

  • Create a Github Issue: Harmonize all post award document classes such as despatch advise to use
    The epo:associatedWith rather than a direct link to an epo:Document.
    Also add a link from the lines to a document.

z8BM81bbOD8bgAAAABJRU5ErkJggg==
fxg9J6ikIYVjAAAAAElFTkSuQmCC
Aym7ClPzXPmo+qggYSvxVLTyi8B58A0khqRu2+wrKAAAAAElFTkSuQmCC
dNUa2Q9w4AkAAAAASUVORK5CYII=

Working Group Meeting

Date: 28/01/2025
Participants: Victorio Bentivogli, Paul Donohoe, Ioannis Fountoukidis, Yves Jordan, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

During the meeting, definitions for the following BTs that appearon the Annex of Regulation 2023/2884:

  • BT-776 did not have any impact on the Ontology.

  • BT-810

    • Is the indicator attribute epo:isCompliantToEnergyEfficiencyDirective needed? It was decided that this indicator will not be modelled since if it is true we will have an instance of epo:EnergyEfficiencyInformation.

  • BT-811

    • Two code lists are needed:

      • Energy-efficiency-Item (already in ePO)

      • Energy-efficiency-Basis (not in ePO)

    • As a result, at-voc:energy-efficiency-basis was created, and linked to epo:EnergyEfficiencyInformation. (see diagram below).

gfJHGSczAVwAAAABJRU5ErkJggg==

  • Create two diagrams in ePO (1 for competiton and 1 for Lot-result) for epo:EnergyEfficiencyInformation class.

  • 813 and 814 are paired.

  • BT-814 :

    • It was discussed that this will be implemented with the SDK implementation., not with the Regulation 2023/2884.

    • Two predicates connecting epo:EnergyEfficiencyInformation to epo:Quantity will be epo:hasConcumptionQuantity and epo:hasSavingsQuantity.

    • The guides/gde_004_eed.pdf · main · eProcurement Group / eForms Group / Docs · GitLab Guide was consulted.

    • At the level of epo:EnergyEfficiencyInformation we will have epo:EnergyEfficiencyItem.

m+CvNcVjQo46cQQojo9v8AKFBifwwbFF4AAAAASUVORK5CYII=

Working Group Meeting

Date: 23/01/2025  
Participants: Peter Borresen, Paul Donohoe, Yves Jordan
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • eFulfilment meeting regarding Receipt Advice.

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]

  • Phttps://github.com/OP-TED/ePO/issues/529[otential problem with modelling of epo:Period ]ePO #529

  • Mapping of at-voc:timeperiod to the OWL Time Ontology ePO #681

Discussions

During the first part of the WGM, eFulfilment and specifically Receipt Advice was discussed: Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.

Regarding the “Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]” github issue:

  • Examples of T01 , and T02 eForms were given to the WGM.

  • Regarding the following fields: Τhey are just for T02 and are about a Tender, so they should be put in a class on the level of epo:TenderAwardOutcome. This class should be named epo:TenderAwardOutcomeInformation. Another class: epo:ContractCondition was added.

    • OPP-080-Tender: Kilometers Public Transport: Represented as a predicate to the epo:Quantity class.

    • OPP-035-Tender: Revenues Allocation of tickets sales code uses the following codelist With only one value.

    • OPP-032-Tender: Revenues Allocation: Add epo:hasTicketsSalesRevenueAllocation xsd:decimal, [0..1] attribute on epo:TenderAwardOutcomeInformation.

    • OPP-030-Tender: Contract conditions Code: uses the following codelist.

    • OPP-031-Tender: Contract Conditions Description (other than revenue allocation): epo:hasContractConditionsDescription rdf:plainLiteral. [0..1] attribute on epo:ContractConditio.n

    • OPP-033-Tender: Penalties and Rewards Code: has only one value (found here). Not going to implement.

    • OPP-034-Tender: Penalties and Rewards Description: epo:hasPenaltiesAndRewardsDescription rdf:plainLiteral [0..1] attribute to to epo:TenderAwardOutcomeInformation.

KCzrishwAAAPy6IAAAACDbpXdNkIUgAAAAvygIAAAAyHbbCZCNPj9SAADwS4AAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAYEAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAYEAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAfltO7kJAAAAAAAAeCAgAAAAAAAAAHhAIAAAAAAAAAB4QCAAAAAAAAAAeED+H2itRRxdk7YeAAAAAElFTkSuQmCC

  • BT-127-Notice:No modification will happen for now.

cXfckNAKrHAJr3udMi82hMAPAfCbarVEStLmMAAAAASUVORK5CYII=

Action Points

  • Create a Github issue: For the Receipt Advice ePO diagram: To represent the action-code and reject-reasons codelists also at the level of the epo-ful:ReceiptAdvice.

mqVvqbbcXMAAAAAElFTkSuQmCC

Working Group Meeting

Date: 21/01/2025
Participants: Paul Donohoe, Yves Jordan, Dragos Stoica Model editor: Andreea Passare Note editor: Achilles Dougalis

Agenda

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

Discussions

Regarding Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726:

Regarding OPT-070-Lot: * An example of a Call For Expressions Of Interest document was presented (F_CEI_EN_DRAFT_2019-03-25.pdf). The ePO team used the document to create a CM diagram for Call For Expressions Of Interest. * The latest Notice-types.json eforms document was consulted. * Class epo-not:PINTransportationNotice was created as seen on the diagram below.

M78XFT1lwMAAAAAASUVORK5CYII=

  • Class epo-not:CANTransportationNotice was created as seen on the diagram below.

s5jrpLAZ8rpz6aY3x9XxWs+f8BnMPcbaw09RIAAAAASUVORK5CYII=

  • It appears that class epo-not:CallForExpressionOfInterest was already implemented in the ePO as epo-not:NoticeCEI. To discuss the removal of epo-not:CallForExpressionOfInterest in a future WGM.

Regarding OPT-071-Lot :

  • The Customer-service codelist was found and does not currently exist in ePO and will be added.

  • It was mentioned that For T02 and T01, epo:LotGroup is Forbidden

*Class epo:QualityTargetInformation was created; it should always be linked to an epo:ContractTerm.
* at-voc:customer-service was created on the level of epo:QualityTargetInformation. They are both mandatory.
* Attribute epo:hasQualityTargetDescription was created.

J5sV+TexYlQAAAABJRU5ErkJggg==

Regarding Assets in a Contract: (they are all for T02):

  • OPP-020-Contract: Assets related contract extension indicator. Class epo:Asset was created.

  • OPP-021-Contract: Used asset Added dct:description [0..1] for epo:Asset.

  • OPP-022-Contract: Significance (%): Added attribute epo:hasSignificance rdf:PlainLiteral. To be further discussed as concept name may change in the future

  • OPP-023-Contract: Predominance (%): Added attribute epo:hasPredominance rdf:PlainLiteral. To be further discussed as concept name may change in the future

4OUzXEkIrXwAAAABJRU5ErkJggg==

Contract terms and other information of a Tender: These are all T02 Notices. It was decided that the WGM will work on the above fields next WGM on 23/01/2025.

OPP-040-Procedure: Main Nature - Sub Type: at-voc:transport-service was created.

a1HXP6NuObggAAAuHogAMBnpJBJpOL1a8vxBgHgOnD8XQBSOCAAAK4SCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACukf8Pzg4zhbqF9dAAAAAASUVORK5CYII=

Action Points

Working Group Meeting

Date: 16/01/2025  
Participants: Peter Borresen, Paul Donohoe, Yves Jordan, Natalie Muric, Dragos Stoica,
Model editor:  Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Alignment with PEPPOL for eFulfilment #569.

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

  • Potential problem with modelling of epo:Period #529

  • Mapping of at-voc:timeperiod to the OWL Time Ontology #681

Discussions

Regarding the alignment with PEPPOL for eFulfilment #569, it was decided that the alignment between PEPPOL business term requirements and ePO eFulfilment module will continue with the Receipt Advice Data model.

Regarding the new BTs described in Regulation 2023/2884 to ePO concepts.https://github.com/OP-TED/ePO/issues/691[#691:]

  • BT-749: It was discussed that although BT-749 was removed from the regulation, no removal of an ePO concept was needed.

  • BT-681: An attribute for epo:ProcurementElement was added for this. epo:appliesForeignSubsidiesRegulation xsd:boolean[0..1]

aD+H80jDfNt6R55AAAAAElFTkSuQmCC
r83XUG1MDSgAAAABJRU5ErkJggg==

  • A use-case is required to find out in what procurement phase should this codelist be used. This will be done in the future as part of describing the Procurement Process. A link to the Digigrow guide on how to use this codelist was provided: https://code.europa.eu/eproc/eforms/docs/-/blob/main/guides/gde_001_fsr.md?ref_type=heads

  • BT-684: It was decided that this BT will not be implemented for now.

  • BT-681 : Should points to epo:LotAwardOutcome. .

  • BT-685 is for the Tender. There is currently no codelist for this. It should go directly to the epo:LotAwardOutcome class. (via the epo:InternationalProcurementInstrumentMeasuresInformation Class seen in the diagram below)

  • BT-686 : Attribute epo:hasNumberOfTendersConcerned as seen in the diagram below.

  • BT-687 : at-voc:international-procurement-instrument-application As seen in the diagram below.

  • BT-688 :Attribute epo:hasPublicInterestExceptionJustification as seen in the diagram below.

  • The International Procurement Instrument Application vocabulary was consulted. It was mentioned that the Digigrow guide (link above) better explains the above mentioned BTs.

QAAAAASUVORK5CYII=

The epo:InternationalProcurementInstrumentMeasuresInformation Class

  • It is important to note that these IPIs are for third world countries or Tenders that have third country subsidiaries.

Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Lot tenderingTerms Fields were discussed:

    • OPT-070-Lot : Class epo:CallForExpressionOfInterest is a typeOf epo:Notice.

Working Group Meeting

Date: 14/01/2025  
Participants: Paul Donohoe, Yves Jordan, Natalie Muric
Model editor:  Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

Regarding #726

  • The following IDs are mandatory in UBL but not required in eForms, so there is no need to map them to ePO either for Lot or Part:

    • OPT-111

    • OPT-112

    • OPT-113

  • The following Classes were implemented: (also depicted on the diagram below) For the following fields:

    • OPT-110-Lot-FiscalLegis

    • OPT-110-Part-FiscalLegis

    • OPT-120-Lot-FiscalLegis

    • OPT-120-Part-FiscalLegis

    • OPT-130-Lot-FiscalLegis

    • OPT-130-Part-FiscalLegis

    • epo:LegislativeDocumentation

    • epo:FiscalLegalDocumentation

    • epo:EnvironmentalLegalDocumentation

    • epo:EmploymentLegalDocumentation

    • epo:Class epo:Documentation was created that is a generalisation of the above Documentation classes.

    • Predicate providesDocumentation was added fromTaxInformationProvider to epo:Documentation

8iFAAAAAASUVORK5CYII=

  • #691

    • ΒG-700 was mapped to epo:QualificationCriterion.

    • ΒT-806: The codelist used is in eForms (exclusion-grounds-source) and it has 3 values: epo-notice, epo-sub-espd (this might be epo-acc-espd) and epo-procurement-document. We will create 3 attributes at the level of epo:QualificationCriteria for each value:

      • epo:hasQualificationCriteriaStatedinNotice

      • epo:hasQualificationCriteriaStatedinESPDRequest

      • epo:hasQualificationCriteriaStatedinProcurementDocuments.

    • BT-821: uses the same codelist as BT-806.

    • BT-67(a), BT-77(b): epo:hasExclusionGroundType predicate connected to at-voc:exclusion-ground was added.

    • BT-748 At-voc:usage will not be used anymore. Instead we create predicates epo:doesNotRequireSelectionCriterionType epo:hasUnknownUsageOfSelectionCriterionType connected to at-voc:selection-criterion codelist. that will be used in case a specific selection criterion is not used or is not yet known.

TED Developer Docs

This website is managed by: Publications Office of the European Union

Need Help?

Follow us

Legal

About us

Other services

Discover more on europa.eu

Contact the EU

Social Media

EU institutions and bodies